בשנים האחרונות יצא לי לנהל לא מעט פרויקטים.
יצא לי גם להיות שותף לפיתוח פרויקטים רבים אחרים (בתפקידים שונים ומגוונים) ולצפות במנהלים ובאופן ההתמודדות שלהם עם הסיטואציות השונות בפרויקט.
אני זוכר שהייתי מופתע (למרבה הצער, בכל פעם מחדש) עד כמה קל לפספס את מטרות הפרויקט, להתרחק בצורה משמעותית מההערכות והתקציב (פי 3 ופי 4) ולגלות שלמרות שהתבצע design דקדקני בתחילת הפרויקט צצו לאורך כל הפרויקט נושאים חדשים ושינויים בנושאים קיימים.
בשנים האחרונות עולם ניהול הפרויקטים עבר מהפכה תפישתית אשר לוקחת את הבעיות הנפוצות שקיימות בניהול ובחיי פרויקטים ומייצרת עבורם שיטות עבודה מתקדמות וחדשניות אשר "מחבקות" את השינוי, מבינות שזה חלק מהתהליך ודואגות לוודא שהצוות עובד על הדברים החשובים ביותר בכל רגע.
מתודולוגיות אלה בדרך כלל משוייכות לתפישה האג'ילית (Agile) אשר מעודדת עדכון תמידי של סטאטוס המשימות בפיתוח פרויקטים, טיפול מיידי במשברים ותקלות ושמות דגש על אדפטציה (הסתגלות), ניהול עצמי ומיקוד סביב הערך אשר נוצר ללקוח.
אחת מהמתודולוגיות הללו היא Scrum.
בשנים האחרונות נחשפתי מספר פעמים למושג, אך לא זכיתי להשתתף בפרויקט קלאסי שמשתמש במתודלוגיה הזאת היות והשימוש במתולוגיה מצריך שינוי תפישתי די רציני בארגון.
מוזר לראות שארגונים טכנולוגיים רצים אחרי הטכנולוגיות החדשות בקצבים מסחררים, מוכנים לבנות תוכנה על בסיס Beta Versions של כל מיני רכיבים ואפליקציות ולא מנסים לבדוק בצורה רצינית אם שיטות הניהול בהן הם משתמשים לפרויקטים הטכנולוגיים שלהם, פשוט מיושנות :(
מוזר עוד יותר, שאפילו כאשר הסטטיסטיקה גרועה עד כדי כך, שיש לא מעט בתי תוכנה אשר ויתרו כליל על תחום פיתוח הפרויקטים והוציאו אותו מסל השירותים שלה, עדיין, לא מנסים לבדוק האם יש שיטות ניהול פרויקטים אשר יכולות לשפר (ולו במעט) את תוצאות הפרויקט.
בסרטון הבא תמצאו תיאור מוצלח של scrum ב-10 דקות
סקראם ב-10 דקות
מעורבות הלקוח הינה חלק בלתי נפרד מפרויקט scrum טיפוסי.
היות והצוות מתרכז בייצור ערך ללקוח, על הלקוח לוודא באופן שוטף שעדיפויות הפיתוח מוגדרות נכון ושהתוצרים שפותחו עומדים בדרישותיו.
הלקוח צפוי לראות תוצרים בתדירות גבוהה באופן יחסי ולכן יוכל כבר בשלבים מוקדמים של הפרויקט להגיב ולהדגיש מה באמת חשוב לו.
המשך יבוא (חלק ב')....
יצא לי גם להיות שותף לפיתוח פרויקטים רבים אחרים (בתפקידים שונים ומגוונים) ולצפות במנהלים ובאופן ההתמודדות שלהם עם הסיטואציות השונות בפרויקט.
אני זוכר שהייתי מופתע (למרבה הצער, בכל פעם מחדש) עד כמה קל לפספס את מטרות הפרויקט, להתרחק בצורה משמעותית מההערכות והתקציב (פי 3 ופי 4) ולגלות שלמרות שהתבצע design דקדקני בתחילת הפרויקט צצו לאורך כל הפרויקט נושאים חדשים ושינויים בנושאים קיימים.
בשנים האחרונות עולם ניהול הפרויקטים עבר מהפכה תפישתית אשר לוקחת את הבעיות הנפוצות שקיימות בניהול ובחיי פרויקטים ומייצרת עבורם שיטות עבודה מתקדמות וחדשניות אשר "מחבקות" את השינוי, מבינות שזה חלק מהתהליך ודואגות לוודא שהצוות עובד על הדברים החשובים ביותר בכל רגע.
מתודולוגיות אלה בדרך כלל משוייכות לתפישה האג'ילית (Agile) אשר מעודדת עדכון תמידי של סטאטוס המשימות בפיתוח פרויקטים, טיפול מיידי במשברים ותקלות ושמות דגש על אדפטציה (הסתגלות), ניהול עצמי ומיקוד סביב הערך אשר נוצר ללקוח.
אחת מהמתודולוגיות הללו היא Scrum.
בשנים האחרונות נחשפתי מספר פעמים למושג, אך לא זכיתי להשתתף בפרויקט קלאסי שמשתמש במתודלוגיה הזאת היות והשימוש במתולוגיה מצריך שינוי תפישתי די רציני בארגון.
מוזר לראות שארגונים טכנולוגיים רצים אחרי הטכנולוגיות החדשות בקצבים מסחררים, מוכנים לבנות תוכנה על בסיס Beta Versions של כל מיני רכיבים ואפליקציות ולא מנסים לבדוק בצורה רצינית אם שיטות הניהול בהן הם משתמשים לפרויקטים הטכנולוגיים שלהם, פשוט מיושנות :(
מוזר עוד יותר, שאפילו כאשר הסטטיסטיקה גרועה עד כדי כך, שיש לא מעט בתי תוכנה אשר ויתרו כליל על תחום פיתוח הפרויקטים והוציאו אותו מסל השירותים שלה, עדיין, לא מנסים לבדוק האם יש שיטות ניהול פרויקטים אשר יכולות לשפר (ולו במעט) את תוצאות הפרויקט.
בסרטון הבא תמצאו תיאור מוצלח של scrum ב-10 דקות
סקראם ב-10 דקות
מעורבות הלקוח הינה חלק בלתי נפרד מפרויקט scrum טיפוסי.
היות והצוות מתרכז בייצור ערך ללקוח, על הלקוח לוודא באופן שוטף שעדיפויות הפיתוח מוגדרות נכון ושהתוצרים שפותחו עומדים בדרישותיו.
הלקוח צפוי לראות תוצרים בתדירות גבוהה באופן יחסי ולכן יוכל כבר בשלבים מוקדמים של הפרויקט להגיב ולהדגיש מה באמת חשוב לו.
המשך יבוא (חלק ב')....
אורי שמחוני, מנכ"ל משותף בפרופר דבלופמנט בית תוכנה איכותי
לשירותי תוכנה, מיקור חוץ, ופיתוח פרויקטים.
לשירותי תוכנה, מיקור חוץ, ופיתוח פרויקטים.
